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(57) Abstract 

A bill editor, generator, messaging, and insert system and method comprises a portion of a bill production pnsccssor (15) designed 
to create monthly billing statements (28) which are sent to customcre and which detail charges incurred over the course of a billing cycle. 
The bill editor and generator (151) allows billing personnel to design a bill using static text, dynamic text, and paragraph areas. Once the 
report/bill is defined, the report definition is stored in temporary memory for later use. The report definition file defines how the report is to 
appear and where the data used in the report is stored. The report generator, when subsequently ran. uses the predefined report definition 
to retrieve data from die database and generates the report as defined by the report definition file. The bill messaging and insert system 
(152. 153) deteimines. based on assigned priority, criteria and weight and space limitations, the messages and notices to be included in a 
customer billing statement 
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BILLING SYSTEM AND METHOD 

TECHNICAL FIELD OF THE INVENTION 

This invention relates in general to the field of data communication 
and more particularly to a system and method for the production of billing 
statements. 

BACKGRO UND OF THF INVENTION 

Service and product providers must bill their customers. To do so, 
these service and product providers, such as cable television operators, local 
telephone service providers, long distance telephone providers, and credit 
card companies, must produce periodic billing statements for each of their 
customers. In the case of a cable television operator, each customer receives 
a monthly billing statement. A single cable television company may operate 
numerous cable television franchises in several geographic regions, covering 
millions of customers. Each of these customers receives a bUling statement 
each month. 

Billing statements are often printed and mailed by bill renderers, 
which a service provider, such as a cable television operator, will contract 
to produce its billing statements. In this arrangement, the service provider 
often fiimishes the bill renderer with the customer data to be printed on the 
billing statements. 

Prior to printing the bUls, they must be generated, edited and 
appropriately messaged. As far as generating the bills are concerned, it is 
necessaiy to detennine where on the customer billing statement the various 
textual information is to appear. Ideally, the service or product provider 
would like to have the flexibility to change the fomat of the billing 
statement without having to physically type the textual information from 
scratch upon each change in the bill run format. Billing and reporting 
information traditionally has been presented in a fonnat with little or no 
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flexibility for altering, without significant effort, the presentation of the 
information appearing on the bill or report. 

As far as biU messaging is concerned, it is necessary to include a 
variety of messages, notices and inserts with the biU. However, there are 
5 limitations on how much material may be included on a standardized bUling 
statement, which usually consists of a perforated sheet of paper, a portion of 
which is returned with payment. When all of the messages will not fit on the 
available space on the bill, some of the messages are merely omitted, 
regardless of priority or importance. There is no known system for 
10 prioritizing the universe of messages that could appear on a bill and then 
print them on the available space according to their priority. In addition, 
there are weight considerations which must be observed to avoid having flie 
customer billing statement exceed the cost of first class postage. 

These and other considerations are addressed by the bill generator, 
15 editor and messaging system and method according to the preferred 
embodiment 

RI IMMARY OF THF INVENTION 

It an object of the present invention to provide a bill editor and 
generator which is flexible in its abiUty to modify the forniat of the customer 

20 billing statement. 

It is a fiirther object of the present invention to provide a bill editor 
and generator which facilitates the process of bill editing and generating. 

It is a fiirther object of the present invention to provide a bill 
messaging system which prints notices and messages on a customer billing 
25 statement according to a predetermined priority in the space allocated on the 
billing statement for such notices and messages. 



A 
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It is a fiuther object of the present invention to provide a bill insert 
system which provides inserts to the customer billing statement according 
to a predetennined priority without exceeding the cost of the prevailing 
weight limit of tfie preferred postal class. 

These and other objects of the invention are accomplished by a 
report/bill editor and generator and messaging system and method of the 
preferred embodiments. The terms biU and report are used interchangeably 
and should be understood as such. The bUl/report editor and generator 
system and method comprises a single module in the bill production 
processor. The report editor is a graphical editor which allows a report 
designer to use a palette of tools to customize where data is to appear on a 
report or bill. The report designer wUl decide how the report^ill wiU 
generally appear, and using the tools, create a graphical layout of where the 
textual inforaiation wUl physically appear on the report. The report editor 
accesses database catalogs which contain table names, table column names 
and stored procedures. The report generator fecilitates generation of reports. 

The report designer has at least three types of tools to generate the 
report's layout, static text tools, dynamic text tools and paiagr^h areas. 
Static text refers to elements such as labels and heading appearing in the 
report and their geometries and contents as well. Dynamic text refers to data 
retrieved from the database. The dynamic aspects of the report editor and 
generator refer to the order in which the paragraphs are to be generated in 
the report, and the stored procedures used to retrieve the data. Finally, 
paragraphs and paragraph areas refer to areas allocated on the report where 
repetitive infonnation is to appear. Once defined, paragraphs describe die 
mutual containment relationships of text. 
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Once the report editor has defined the layout of a report, a report 
definition file (RDF file) is stored in temporary memory. At some time in 
the fiiture. the report may be run by a report generator program. The report 
generator program reads the RDF file fi-om temporary memoiy. The RDF 
5 file describes how the report is to appear, where the data is stored and where 
it is supposed to draw the data on the report. The report generator queries 
the database under the control of the RDF file. The report generator pulls 
the data specified by the RDF file, and prints it in the mamier specified by 
Ae RDF file. The report generator, on user demand, uses a report definition 
0 to get data from the database (and the user, if necessary) and generates the 
leportdefinedbyfliereportdefinition. TTie report generator can generate the 
report in any of die typical places supported on the native platform: screen, 
paper or disk. In other words, the user can specify that instead of printing 
the infonnation on paper, it can be drawn in a window on a computer screen, 
15 or written to a file on a disk, which can be accessed at a later time without 
having to go back to the database. 

The bill message, notice and insert system and method comprises a 
bill definition portion followed by a biUnm portion. The bill defmition 
portion comprises a series of definitions which are input by the billing 
20 persomiel whereas the bill nm portion detennines which messages, notices 
and inserts eventoally make it into the customer bUling statement. More 
particularly, in the bill definition portion, the billing persomiel defme the 
universe of available messages for a given billing cycle. The billing 
persomiel also identify a universe of inserts available for die bUling cycle. 
25 Each insert has a known weight. Next, the billing persomiel defme the 
criteria of infonnation to be included on the biU. This could include account 
infonnation, collections history, product history, etc. Next, the billing 
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personnel assign a priority to each of the messages, notices and inserts. In 
other words, the billing personnel interact with a system to specify the types 
of messages, the criteria of information to be included in that particular bill 
nm and Ac associated priority of tfie messages and notices. The system tfien 
5 processes this infoimation in the bill nm portion to generate a bill which 
conforms to the weight and space limitations of the customer billing 
statement. 

More particularly, the bill run portion of the system then qualifies 
each message, notice and insert against stored information about each 

10 customer. Only messages, notices and inserts relevant to a particular 
customer qualify for that customer. The qualifying messages and notices are 
stored in temporary memoiy. Then, all of Ae qualifying messages and 
notices are arranged according to priority, and only those that fit on the bill 
are eventually printed. At the same time, all of the qualifying inserts are 

15 stored in temporary memory. Only those inserts which, according to the 
predetermined insert priority, will make the final bill equal to or less than the 
weight limit of the preferred postal class are included in the customer billing 
statement. 

Odier objects, features and advantages of the preferred embodiments 
20 will become apparent when the detailed description is read in conjunction 
with the accompanying drawings. 
BRIEF DESCRIPTION OF THE DRAWINGS 

FIG. 1 is a graphical representation of the preferred embodiment 
system of the present invention indicating the data flow of the generation, 
25 messaging and printing of a biUing statement. 
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FIG. 2 is a graphical representation of the bill editor and generator 
module of Ae bill production processor according to the preferred 
embodiment. 

FIG. 3 is a flow representation of the bill editor and generator module 
according to the preferred embodiment. 

FIG. 4 depicts a message generated by the bill editor and generator 
according to the preferred embodiment. 

FIG. 5 depicts a table generated by the bill editor and generator 
according to the preferred embodiment. 

FIG. 6 is a high level flow diagram of the bill messaging and insert 
system according to the preferred embodiment. 

FIG. 7 is a detailed flow diagram of the bill messaging and insert 
system according to the preferred embodiment. 
^T^T M\ Fr rMTcrPTPTTON OF THF PFFFFff R FD FMBODIMENTS 

A service or product provider, such as cable television providers, 
local telephone service providen, long distance telephone providers, and 
credit card companies, store customer data on one or more databases within 
a customer managemem system. The customer management system 
manages the data comprising each customer account. As a customer's 
20 account changes over time, as a result of, for example, service and product 
oriers and deletions, the customer management system updates the customer 
data so that an accurate current and historical record is maintained of each 
customer's account history. HGURE 1 is a graphical representation 
of a customer management system 10 of a service provider. A customer 
25 management system may include one or more data servers 12 comiected 
across one or more communications links 13 to one or more customer 
databases 14. Databases 14 may be all located in one physical location or 
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may be located in separate physical locations. Each of data servers 12 is 
connected across one or more communications links 17 to a bill production 
processor 15, which processes and handles the customer data maintained in 
customer management system 10. 
5 The bill production processor system 15 of the present invention 

includes a bill editor and generator module 151, a bill messaging extraction 
module 152, a bill insert manager module 153 and a bill format manager 
module 154. All the customers of a service provider are not billed at the 
same time each month. A service provider will often bill its customers on 
10 a rolling monthly schedule so that different sets of customers, perhaps 
differentiated by geographic region, are each billed during different periods 
of each month. At the time of the month that a given set of customers is to 
be billed, bill production processor 15 extracts from customer databases 14 
the customer data that is to be printed on the billing statements provided to 
1 5 the billed customers. 

The input to the bill format manager module 154 is the unfonnatted 
customer data for each customer to be billed. The unfonnatted customer 
data provided at the output of bill fonnat manager module 154 includes 
account status information, customer address infonnation, account balance 
20 infoimation, legal notices, promotional notices, and other data for each of 
the customers to be billed. 

Bill fonnat manager module 154 receives the unformatted customer 
data from modules 151, 152, 153 and converts this data according to a bill 
renderer definition fonnat. The output of bill fonnat manager module 154 
15 is the formatted customer data for the set of customers to be billed. The 
ou^ut of bill fonnat manager module 154 is saved in a fonnatted customer 
billing file 20, which may be any suitable storage medium, including a tape, 
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disk, or optical storage medium. Formatted customer bUling file 20 contains 
the formatted customer data for each of the customers to be billed. 

Formatted customer biUing file 20 is provided to one of any number 
of available bill renderers 22. A bill renderer interpreter module 24 (1) 
interprets the syntax of formatted customer billing ffle 20, which is fonnatted 
according to the bill renderer definition format, (2) extracts the customer 
data from formatted customer billing file 20, and (3) sends the interpreted 
and extracted data to a printer 26. which prints a series of customer billing 
statements 28. 

The output of bill format manager module 154 is formatted according 
to the bill renderer definition format. The bill renderer definition format 
provides a simple format for the service provider's customer data. The bill 
renderer definition format of the present invention is easily inteipretable by 
the bill renderer interpreter module 24 of each of the service provider's biU 

15 renderers 22. 

With reference to FIG. 2 in conjunction with FIG.l, there is shown 
an overall schematic of Ae report editor and generator module 151. The 
terms and "report" are used interchangeably and should be understood 
as such. The report editor and generator has two separate components which 
20 work together to generate a bill. The first, report editor 1511. is the portion 
of module 151 directed to generating the graphical layout of a bill or report 
on paper or a screen. The second, report generator 1512. is the portion of 
module 151 directed to the generation of report based on the instructions 
contained within report editor definition file 1513. 
25 A user, at 15 14, using a palette of tools defmes the overall layout of 

the report. When a particular tool is specified, whether it is static, dynamic 
or paragraph text, the report editor 151 1 accesses database catalogs 1515. 
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The editor accesses the database catalogs to allow the user to choose the 
stored procedures which are run when the report is generated. In other 
words, the user 1514 selects the stored procedures to be used by the report 
for execution at a later time. Once the report is defined, it is stored in a 
report definition file (RDF file)1513. The RDF file 1513 is a temporary 
memoiy which stores the overall layout of the bill, but not specific customer 
data. 

When the biUing personnel desires to run a bill, the report generator 
segment 1512 of the system is run. The report generator 1512 reads the RDF 
file 1513, which describes how the report it to appear, where in the database 
15 1 6 Ae customer data is stored and where to draw the data on the report. 
The report generator 1512 queries the database 1516 under the control of the 
RDF file 1513. The report generator 1512 pulls the data specified by the 
RDF file 1513. and prints it as a report 15 17 in die manner specified by the 
RDF file 1512. TTie user can specify that instead of printing the information 
on paper, it can draw it in a window on a computer screen, or write it to a 
file on a disk, which can be accessed at a later time without having to go 
back to die database 1516. 

Witii reference to FIG. 3, there is shown a schematic flow diagram of 
the steps used by the billing personnel to edit and generate a report. Report 
editor 151 1 is first used to define the appearance of the report. Then, report 
generator 1512 is used to collect die appropriate information required by die 
report definition file 1513. In step 1560. die billing persomiel lays out die 
graphical elements which will appear on die bill. These include static text 
elements of step 1562, which consist of unchanging text, such as field 
captions, labels, headings, etc. In addition, in step 1564, dynamic text 
elements are input by die billing persomiel. Dynamic text is text tiiat 
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depends on a table column or some other variable quantity, such as the 
cuirent date, the current time, and page number. As is well known in the art, 
data in relational databases are organized in tables. For instance, the 
database may contain a customer table, which includes important 
5 information pertaining to the customer. Data in relational databases is 
generally organized in rows and columns. A specific customer in a customer 
table is typically represented in a single row, along which all of the 
information about that customer is stored The columns of the customer 
table might include first name, last name, customer ID, current balance, etc., 

10 respectively. 

Next, the billing personnel in step 1566 defines the paragraph area 
scripts. Paragraphs are generated within paragraph areas. A paragraph area 
appears widiin a larger paragraph. Each paragraph in tiie report is associated 
with a particular paragraph area in the report, and may only be generated 

15 within that paragraph area. A paragraph area is divided into one or more 
equal width cohimns. A paragraph associated with a given paragraph area 
has a width equal to the width of either the paragraph area or one of its 
columns. The order in which paragraphs are to be generated in the report 
and the stored procedures that are to be called to retrieve data are in a 

20 paragraph area script 

Paragraphs are generated within paragraph areas under the control of 
the script. Associated with each paragraph area is a paragraph area script, 
which constructs the paragraph area with the data obtained when the report 
generator 1512 queries the database 1516. The scripting language is 

25 preferably graphical, and there may or may not be textual representation of 
it. One example of a textual representation of the scripting language syntax 
is shown below. When all paragraph areas in a containing paragraph are 
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full, and another paragraph is generated in one of the paragraph areas, 
another page is generated for the report. 

Once the report is defined by static, dynamic and paragraph text, it is 
reduced to an RDF file at 1568 and stored in tempoiaiymemoiy 1513. At 
some later time, the billing personnel can generate die report. Upon 
instmction to do so fi-om the billing personnel, the billA-eport generator 1512 
reads the RDF file 1513, which describes how the report is to appear and 
where the data is stored in database 1516. The report generator 1512 
interprets die contents of the RDF file at step 1570 and at step 1572 has the 
database execute stored procedures. Finally, Ae report generator 15 12 pulls 
the data specified by the RDF file 1513, and prints it in step 1574 in the 
manner specified by the RDF file 1 5 1 3. 

As is apparent from the foregoing, the RDF file is designed to 
provided support for specification of all manner of printed output, from 
traditional line-oriented reports, such as pay-per-view order summaries, to 
forms, such as bills and work orders. The RDF file feattires easy 
specification of repetitive or one-time outputs in units called paragraphs, 
with a natural connection to data sets modeled as die result sets of stored 
procedure calls to a relational database. Advantageously. RDF files are 
20 amenable to graphical editing. 

The following is a listing of RDF syntax and semantics. It consists 
of an alphabetical listing of productions, each defining the allowable 
representations of some nonterminal. The syntax is presented in a veiy 
stylized foim. Nonteiminals are in angle brackets; tenninals are in boldface. 
Pseudoteiminals are in italics, and are explained following die syntax. Text 
from a dash to the end of die line is commentaiy. Repetition of zero or more 
symbols is denoted by braces. Alternation between symbols is denoted by 
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<binding> 

<col\mms> 
<dynamic text> 



a vertical bar. Numbers denoting origins and sizes are integer numbers of 
points, except where otherwise indicated. There are 72.27 points per inch. 

With one exception, line breaks are significant in this syntax and 
appear where shown. The exception is <page info>: due to space 
limitations, the representation of <page info> spans multiple lines, but in fact 
it must all appear on a single line. The distinguished symbol, i.e., the place 
to begin, is the nonterminal symbol <report>. 

^background color> - Color 

- * an identifier denoting a data element 
(see Appendix A) 

- - number of columns in paragraph area 

- DynamicText 
<binding> 

<ori x> <ori y> <width> <height> <justif> 
<background color> 
<foreground color> 
<font> 
= <dynamic text> 
I <line> 

I <paragraph area> 
I <picture> 
I <rectangle> 
I <rounded rectangle> 
I <static text> 

<font> = ^^"^ 

<foregroimd color> - Color 

<full width> = - 1 if fiill widdi, 0 if column width 



<elementP^ 
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<grid size> 

<height> 

<justif!> 

<landscape> 

<ine> 



<margin bottoin> 

<margm left> 

<margm right> 

<margin top> 

<orix> 
<ori y> 
<overlap x> 
<overlap y> 
<page iiifo> 



<page info version> 



- - granularity of editing grid 

- -height 

= - 0 if left, 1 if center, 2 if right 
= - 1 if landscape, 0 if portrait 

- Line 

<ptl x> <ptl y> <pt2 x> <pt2 y> 
<background color> 
<foregroiind color> 
= - paper bottom margin 

(nonintegral number of points) 

- - paper left margin 

(nonintegral number of points) 

- - paper right margin 

(nonintegral number of points) 
= - paper top maiigin 

(nonintegral number of points) 
= X coordinate of origin 
= - y coordinate of origin 

- 0 

- 0 

- <page info versionxpaper typc> 
<landscape> <poster> <paper width> 
<paperheight> <margin leftXmargin 
right> <margin top> <margin bottom> 
<scale mode> <scale x> <scale y> 
<overlap x> <overlap y> 

= a 
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<paper height> 

<paper type> 
<paper width> 

5 

<par^aph> 



10 

<paragraph area> 

15 

<paragraph identifier> 
20 <picture> 



<picture linO 
25 <poster> 
<ptl x> 
<ptly> 
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- - height of paper 

(nonintegral number of points) 
= PaperType 
. . width of paper 

(nonintegral number of points) 
= Paragraph 

<paragraph identifier> 

<full width> <height> 

<grid size> 

- number of elements 

{ <clemcnt?^ ) 
= ParagraphArca 

<script> 

<columns> <ori x> <ori y> <width> 
<height?> 

- number of paragraphs 

{ <paragraph> } 
- - a name uniquely identifying the 

paragraph witfiin its paragraph area 
= Picture 

<ori x> <ori y> 

- number of picture lines 

{ <picture line> } 
. - 64 hex digits of Neuron Data image data 
= 0 

= - X coordinate of first point 
= - y coordinate of first point 
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<pt2x> 
<pt2y> 

<RDR version> 
<rectangle> 

5 

<report> 

10 

<roiinded rectangle> 

15 

<scale inode> 

<scale x> 
<scale y> 
20 <script> 

<static text> 

25 

<text> 
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- - X coordinate of second point 

- - y coordinate of second point 
= a 

= Rectangle 

<ori x> <ori y> <width> <height> 
<backgroimd color> 
<foregroiind color> 

- Report 
<RDF version> 
<page Info 
<paragraph area> 

- RoundedRectangle 

<ori x> <:ori y> <width> <height> 
<background color> 
<foreground color> 
= 3 

- 1 

= 1 

=-a paragraph area script (see Appendix A) 
= StaticText 
<text> 

<ori x> <orI y> 
<l)ackground color> 
<foreground color> 
<fonl> 
- -static text 
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<widtif> 

Color 

Font 

PaperType 
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= -widft 

= ihe name of a Neuron Data color resource 
- the name of a Neuron Data font resource 

1 US letter 

2 US legal 

3 US tabloid 

4 US ledger 
etc. 

Associated with each paragraph area is a script, defining how each 
paragraph area is to be rendered. The syntax of paragraph area scripts is 
shown below It uses die same stylized form as the above RDF syntax. The 
distinguished symbol (dial is, the place to begin) is the nonterminal symbol 
<script?>. 

- <expression> 



20 



25 



<argumen1> 
<datasee> 
<data set idcntifier> 
<expression> 

<f oreach statemenC> 



<paragraph idcntifier> 
<paragraph statement> 
<script> 
<stateinent> 

<type> 



<data set identified { <argument> } 
Identifier 
■ Identifier \ Number \ String 

I <type> ( <expression> ) 
= foreach <data set> 
{ <statement> } 
end foreach 

- String 

= paragraph <paragraph identifier> 

- { <statement> } 

= <foreach statement> 1 <paragraph 

statement> 
= Integer 1 Money 1 String | Time 
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Identifier = a sequence of one or more letters, 

digits, underscores, and periods, 
beginning with a letter, and not 
matching any of the above 
boldfaced reserved words — may 
denote a data element, as <data 
set identifier>.<column name> 
^""f^^f = a sequence of one or more digits 

^""'"S - a sequence of zero or more non- 

quote characters, in quotes 
When a paragraph area is to be rendered, the statements comprising 
Its script are executed, in sequence. Execution of a paragraph statement 
simply consists of rendering its identified paragraph, at the next location 
within the paragraph area. Execution of a foreach statement consists of two 
15 actions: 

1) Acquire the data set of the foreach statement. In online 
operation, this involves calling the identified stored procedure 
with the listed arguments. In offline operation, this involves 
reading the next data set from an input file, where the data set 
consists of a number of rows m, a number of columns », « 
column names, and m rows of data, n columns per row. 
2) For each row in the data set, execute the statements of the 
foreach statement, in sequence. 
Two examples of a typical RDF file follow. The reports specified by these 
examples are shown in HGS. 4 and 5, respectively. The first example 
specifies a static message. 



20 
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RDF: 

Report 
a 

a 1 0 0 614.295 794.97 72.27 72.27 72.27 72.27 3 1 1 0 0 
5 ParagraphArea 

paragraph "Paragraph 1" 

1 10 10 614 795 

1 

Paragraph 
10 Paragraph 1 

1 795 
6 
2 

StaticText 
15 Example 1: 

72 205 

Color.White 

Color.Black 

fonts.FontLarge 
20 StaticText 

The simplest report you'll ever need. 

72 229 

Color.Transparent 
Color.Black 
25 fonts.FontLarge 

The next example, the output of which is shown in FIG. 5, displays 
data in a paragraph area contained within the top-level paragraph area. In 
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online operation, the stored procedure lp_jet_subject_cat is the source of the 
data elements subject_cat_cd and subject_cat_desc. In offline operation, 
they come from an input file such as the one following the example. 
RDF: 
5 Report 
a 

a 1 0 0 614.295 794.97 72.27 72.27 72.27 72.27 3 1 1 0 0 
ParagraphArea 
paragraph "Paragraph 1" 
10 1 10 10 614 795 

1 

Paragraph 
Paragraph 1 
1795 
15 6 

4 

StaticText 
Example 2 
205 96 
20 Color.Whhe 
Color.Black 
fonts. FontLarge 
ParagraphArea 

foreach subject_cat paragraph "Paragraph 1" end foreach 
25 1 60 132 494 651 

1 

Paragraph 
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Paragraph 1 

136 

0 

3 

5 Rectangle 
20 0 468 37 
Color.White 
Color .Bladi 
DynamicText 
10 subject_cat.subject_cat_cd 
54 18 10 1 0 
Color.White 
Color.Black 
Font.Noimal 
15 DynamicText 

subject_cat.subject_cat_desc 

271 18 11 1 0 
Color.White 
Color.Black 
20 FontNormal 
StaticText 

Code 

120 120 

Color.White 
25 Color.Black 

FontBold 

StaticText 
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Description 
337 120 
Color. White 
CoIorBIack 
5 FontBold 

Input File: 

subject_cat 
10 11 2 

subject_cat_cd subject_cat_desc 
ADULT|Adult 
ADVEN I Adventure 
CHILD I Children 
15 CNCRT I Concert 

COMDYIComedy 
DRAMAIDrama 
EDUC I Education 
FAMjFamily 
20 HORR I Horror 

MUSCL I Musical Stoiy 
SPORT I Sports 

With reference to HG. 6 in conjunction with FIG. 1, there is shown 
25 a high level flow diagram of the bill messaging extraction module 1 52 and 
bill insert manager 153 according to the preferred embodiment. The bill 
messaging extraction module 152 determines the type of messages and 
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notices that may be included on a customer bUling statement. The bill insert 
manager 153 determines whether inserts, if any, should be included within 
the customer bUling statement based on the total weight of the bill. In Step 
1501 of the bill messaging, notices and inserts process of FIG. 6, the user 
5 first defines a universe of messages, notices and inserts which could be 
included in the customer billing statement. Step 1501 allows billing 
personnel to enter all relevant messages, notices and inserts for a particular 
billing cycle, of which only a small subset may eventually appear in any 
particular customer's billing statement. Thus, by initially inputting a 
10 universe of billing messages, notices and inserts, the billing personnel is 
relieved of having to generate customized billing statements for each 
customer. 

In Step 1502, the universe of available messages are qualified for a 
particular customer, based on known criteria for that customer. If, of a 

15 universe of 50 messages, only 5 are relevant to, i.e., qualify for, a particular 
customer, Ac remaining 45 messages are discarded. 

Next, the messages and inserts are analyzed in Step 1503 to determine 
whether they will conform to the particular format established for that bill 
run. A particular bill format is chosen, perhaps consisting of a single, folded 

20 page, which is perforated so that the bill may be separated into two sections, 
one of which is returned with payment. All of the qualifying messages may 
not fit on the customer billing statement. Step 1503 determines whether 
particular messages will indeed fit on the chosen format for the customer 
biUing statement. For instance, in the case of messages, this means that, of 

25 5 relevant messages, perhaps only 3 will fit on the final statement. Similarly, 
for notices, this means that only the most important notices will be included 
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in the bill, but only if the total weight of the bill is equal to or less than a 
designated postal weight, e.g., one ounce. 

Next, in Step 1504 all qualiiying messages as specified through the 
formatting language transmitted to the bill renderer are printed and all 
5 qualiiying inserts are stuffed into envelopes by Ae bill r^derer. 

With reference to FIG. 7, there is shown a more detailed description 
of the bill modules 152, 153 according to the preferred embodiment. The 
system may be seen as having two operating segments, the bill definition 
segment 1510 and the bill run s^ent 1520, one following the other. In the 
1 0 bill definition segment 1 5 1 0, the universe of possible messages and inserts 
are defined by the billing personnel. Once the universe of messages is 
detennined, tfie bill run segment qualifies die messages for each customer 
and executes a prioritization to determine whether a particular message 
and/or insert will be included in the customer billing statement. 
1 5 In Step 1 5 1 2, the billing personnel defines for the billing period the 

universe of messages that could be included on any given billing statement 
widiout regard to individual customer information. The universe of 
messages are preferably input using a graphical user interface. Alternatively, 
an existing or flat file with a predefined universe of messages is accessed by 
10 tiie billing personnel, who Aen chooses which messages are to be included 
in the sub-universe of possible messages. The types of messages that might 
be included within the universe are varied. For instance, if a customer 
currently subscribes to HBO, one of the messages might include the 
promotion "Free Cinonax in die month of December for all HBO 
15 subscribers, Happy Holidays!" Alternatively, the messages might be notices 
or reminders. For instance, it might remind customers to call "1-800- 
DONTDIG" for assistance concerning where to dig on their property to 
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avoid utility lines. Still farther, the messages could be infonnational, such 
as infonning customers of rate increases/decreases, informing customers of 
deadlines for solicitation of comments concerning changes in rules, 
advertising for an upcoming pay-per-view event, collections messages such 
5 as yom account is past due of $45.00, please pay immediately," etc. 

In Step 1514. the billing personnel identifies for the billing cycle the 
universe of inserts which could be included in any given customer billing 
statement wiAout regard to individual customer information. The universe 
of inserts are input using the graphical user interface. The types of inserts, 
10 like the types of notices, are varied. For instance, they could include 
advertisements, legal notices, promotional coupons for local business which 
have paid for advertising on any of the cable stations, schedule of televised 
evoits, etc. 

After the universe of mess^es have been defmed and identified, the 
15 billing personnel in Step 1516 defines criteria for detennining which of the 
universe of messages, notices and inserts should be included in a particular 
bill nm. The criteria is preferably defmed by the billing personnel using the 
graphical user interface. Alternatively, Ae billing personnel could access a 
flat file having a listing of possible criteria, which are then chosen according 
20 to relevance to the biU run. The criteria of messages is diverse, and could 
include, for example, account information, collections histoiy, product 
history, instructions to send messages and inserts to all customers, only to 
specified customers or some other subset of customers, instructions to send 
messages and inserts to those customers who have been late in remitting 
25 payment in the last three months, diose in a certain zip codes, those 
subscribing to certain channels, etc., to name a few. The billing criteria is 
defined using traditional logic commands (AND/OR etc.) stnmg between the 
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various commands associated with the particular criteria. For instance, the 
criteria for a message could be designed as "All customers in franchise tax 
area 8010 AND in bill cycle 4 AND (have HBO OR Cinemax)". The step of 
setting specified criteria for a bill run is particularly useful in the case where 
a limited bill run is scheduled for a segment of the franchise's customer 
base. The remaining segment of the franchise would thus be excluded from 
the bill run. 

In Step 15 1 8, the billing personnel assigns a priority to each of the 
messages, notices and inserts using, e.g., a scale of 1-10. This qualifies the 
importance of a particular message, notice or insert and the likelihood that 
it is included in a bill run. The higher the priority, the more likely a 
message, notice or insert will be included in a customer billing statement. 
For instance, government sanctioned legal notices would likely be assigned 
a relatively high priority, wdiereas advertising and promotional activities may 
be assigned a relatively lower priority. The billing personnel enters the 
priority of each of fte messages, notices and inserts using the graphical user 
interface. With the conclusion of Step 1518, the bill definition segment 
15 10 is completed. No fiirther input is required by Ae billing personnel. 

The bill run segment 1520 then commences. In Step 1522, each 
message, notice and insert, are qualified against stored information for each 
customer. Only messages, notices and inserts which are relevant to each 
customer individually qualify for that customer. For instance, if messages 
informing customers of imminent repairs m certain zip codes are included 
in the biD lun. customers of other zip codes do not qualify and messages and 
notices are not sent to fliose customws in the non-qualifying zip codes. 
Alternatively, if Cinemax is offering a promotion, e.g., free Cinemax for 
customers with HBO, only those customers who currently subscribe to HBO, 
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but not Cinemax, will receive the notice on their customer billing statement. 
It is possible diat 50 or more messages, notice and inserts will have been 
defined, but only 5 or less qualify for a particular customer. 

In Step 1524, all of the qualifying messages and notices are grouped 
5 together. Based on formatting rules, the messages and notices with the 
highest priority are designated to be printed on the bill first. As described 
previously in connection with the bill editor and generator module 151, 
different message areas are defined on the bill. The formatting rules dictate 
that the highest priority message that can fit into these areas are included on 
1 0 the bill. Since the bill is typically a single, perforated sheet, a limited amount 
of text space is available. If all of the available space on Ae customer billing 
statement has been allocated to messages and notices of relatively high 
priority, any remaining lower priority, un-printed messages are discarded. 
Alternatively, any of the remaining lower priority, un-printed messages may 
15 be stored in the customer's file for incorporation into the next billing run, 
and depending upon whether they are high enough in priority relative to the 
messages and notices for the next succeeding billing run and are not 
otherwise outdated, tiiey may dien be printed on tiie following customer 
billing statement. 

20 In Step 1526, all of the qualifying inserts are grouped together. First 

class postage is typically limited to a specified weight limited, e.g., one 
ounce. Anything above this will require further postage fees. When it is 
considered that tens of thousands of customers must be sent customer billing 
statements every month, the cost of mailing customer billing statements 

25 becomes significant. Thus, any deviation above the weight limit of ftfst 
class postage becomes economically significant on this scale. At the same 
time, however, if a number of inserts qualify for a particular customer, it is 
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desirable to include as many inserts as possible without exceeding the first 
class weight limit. Thus, in Step 1526. the qualifying inserts are chosen 
based upon the assigned priority until the total weight of the bill is equal to 
or less than the prevailing weight limit of the preferred mailing class, i.e., 
one ounce in the case of first class postage. Any of the remaining lower 
priority inserts which are not included in the customer billing statement may 
be stored in the customer's file for incoiporation into the next billing run, 
and depending upon whether they are high enough in priority relative to the 
inserts for the next succeeding billing run and are not otherwise outdated, 
they may then be included in the following customer billing statement. 

Although the present invention has been described in detail, it should 
be understood that various changes, substitutions, and alterations can be 
made without departing from the spirit and scope of die invention as defined 
by the appended claims. 
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WHAT TS CLAIMED IS: 

1 A mefliod of preparii^ a customer billing statement comprising 

the steps of: 

defining at least one billing message to be included on the 

5 customer billing statement; 

defining criteria for including said at least one billing message 

on the customer billing statement; 

assigning a priority for each of said at least one message to be 
included on tiie customer billing statement; and 
10 qualifying each message for each customer based on stored 

customer infoimation. 

2. The method of claim 1 fimher comprising the step of printing 
all qualified messages on the customer billing statement. 

3. The method of claim 2. said printing step comprising the step 
15 of using fonnatting niles to print the highest priority messages that fit on the 

customer billing statement 

4. A system for preparing a customer billing statement 

comprising: 

means for defining at least one billing message to be included 

20 on the customer billing statement; 

means for defining criteria for including said at least one 
billing message on the customer billing statement; 

means for assigning a priority for each of said at least one 
message to be included on the customer billing statement; 
25 means for qualifying each message for each customer based on 

stored customer information. 
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5. The system of claim 5, fiirther comprising means for printing 
all qualified messages on the customer billing statement. 

6. A mediod of preparing a customer billing statement comprising 
the steps of: 

5 identifying at least one insert to be included in Ifae customer 

billing statement; 

defining an insert weight limit for limiting the total weight of 
inserts to be included in the customer billing statement; 

defining criteria for including said at least one insert to be 
1 0 included in the customer billing statement; 

assigning a priority for each of said at least one insert to be 
included in the customer billing statement; 

qualifying each of said at least one insert for each customer 
based on stored customer information; 
15 providing qualified inserts in the customer billing statement 

according to priority. 

7. The method according to claim 6 further comprising the step 
of limiting the weiglit of flie customer billing statement, including inserts, to 
the maximimi weight limit of a preferred postal class. 

^0 8. The method according to claim 7, said limiting step comprising 

the step of limiting the weight of the customer billing statement, including 
inserts, to one ounce. 

9. A system for preparing a customer billing statement 
comprising: 

-5 means for identifying at least one insert to be included in the 

customer billing statement; 
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means for defining an insert weight limit for limiting the total 
weight of inserts to be included in the customer billing statement; 

means for defining criteria for including said at least one insert 
to be included in the customer billing statement; 
5 means for assigning a priority for each of said at least one 

insert to be included in the customer billing statement; 

means for qualifying each of said at least one insert for each 
customer based on stored customer information; 

means for providing qualified inserts in the customer billing 
1 0 statement according to said assigned priority. 

10. A method of editing a customer bill comprising the steps of: 
defining at least one static text element to appear on the bill; 
defining at least one dynamic text elemait to appear on the 

bill; 

15 defining at least one paragraph script area on the bill, said 

static text elements, dynamic text elements and paragraph script area 
comprising a report definition; and 

storing said report definition as a report definition file in 

tempmaiy memory. 

20 11. The method of claim 10, said step of defining static text 

elements comprising the step of accessing database catalogues having a 
plurality of static text elements which can appear on fte bill. 

1 2. A system for editing a customer bill comprising the steps of: 
means for defining at least one static text element to appear on 

25 the bill; 

means for defining at least one dynamic text element to appear 

on the bill; 



wo 97/24680 PCT/US96/20I35 



31 

means for defining at least one paragraph script area on the 
bill, said static text elements, dynamic text elements and paragraph script 
area comprising a report definition; and 

means for storing said report deimition as a report defmition 
5 file in temporary memory. 

13. A method of generating a customer bill comprising the steps 

of: 

defining at least one static text element to appear on the bill; 
defining at least one dynamic text element to appear on the 

10 bill; 

defining at least one paragraph script area on the bill, said 
static text elements, dynamic text elements and paragraph script area 
comprising a report definition; 

storing said report definition as a report defmition file in 
1 5 temporary memoiy ; 

retrieving said report definition from temporary memoiy; 

interpreting said report defmition to determine customer 
specific information to appear on the bill; and 

retrieving customer information from databases to gather 
20 information to be printed on the biU. 

14. The method of claim 13, said step of defining static text 
elements comprising the step of accessing database catalogues having a 
plurality of static text elements which may appear on the bill. 

1 5. The method of claim 13, fiirdier comprising the step of printing 
25 the bill to a screen. 

1 6. The method of claim 1 3, further comprising the step of printing 
the bill on paper. 
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17. A system for generating a customer bill comprising the steps 

of: 

means for defining at least one static text element to appear on 

thebiU; 

5 means for defining at least one dynamic text element to appear 

on the bill; 

means for defining at least one paragraph script area on the 
bill, said static text elements, dynamic text elements and paragraph script 
area comprising a report definition; means for storing said report 

10 defmition as a report defmition file in temporary memory; 

means for retrieving said report defmition fix)m temporary 

memoiy; 

means for interpreting said report defmition to determine 
customer specific information to appear on the bill; and 
1 5 means for retrieving customer information from databases to 

gather information to be printed on the bill. 
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